Technical fields of application for embodiments of the present invention are, for instance, so called “Smart Cities” and comparable scenarios, where a huge number of sensors, e.g. smart meters, is connected to a network infrastructure. Many of these sensors may send data only very infrequently, e.g. once per hour or even once per day, to some sink such as an IoT (Internet of Things) database or server. Sensors either proactively push this data to the centralized IoT server or the latter polls the sensor—either in fixed intervals or on demand.
If permanent flow rules were to be installed for every sensor in the network, this would quickly overload the flow tables of the network's switches, especially those located closer to the IoT servers. While for the uplink direction (i.e. from the sensors to the servers), aggregate forwarding based on destination IP address would alleviate much of this problem, the issue cannot be avoided in the downlink direction which requires more granular flow rules.
Now it is certainly possible to use reactive flow rule installation in the flow-based programmable network devices (e.g. SDN switches) of the network infrastructure that carry data packets from the sensors to the IoT servers or to any other sink. With this, a sensor (or its IoT gateway) would send its data packet to the ingress switch, which—assuming an SDN network and in the absence of any matching rule—would consult an SDN controller and thus get a flow rule on demand. This rule could have an associated timeout value, so would disappear after a while. This method alleviates the flow rule overload problem as it distributes flow rule entries over time (provided sensors do not send all at the same time, which seems like a reasonable assumption in a heterogeneous system such as a Smart City network). However, it comes at the expense of high signaling load between switches and SDN controller. Millions of sensors will generate millions of message exchanges along the forwarding path in regular intervals. This may be considered a problem in itself.
An alternative solution would be the implementation of flow tables “expansions” (as described, for instance, in Roberto Bifulco and Anton Matsiuk: “Towards Scalable SDN Switches: Enabling Faster Flow Table Entries Installation”, in Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication (SIGCOMM '15). ACM, New York, N.Y., USA, 343-344, DOI=http://dx.doi.org/10.1145/2785956.2790008, or in Naga Katta, Omid Alipourfard, Jennifer Rexford, and David Walker: “Infinite CacheFlow in software-defined networks”, in Proceedings of the third workshop on Hot topics in software defined networking (HotSDN '14). ACM, New York, N.Y., USA, 175-180, DOI=http://dx.doi.org/10.1145/2620728.2620734). For example, one could use the switch's CPU to implement software flow tables, which can hold large numbers of entries, however, at the cost of limited forwarding throughput and limited scalability in respect to the data plane traffic handling.